Developer CD Series 1995 February: Tool Chest/Dev.CD Feb 95/Dev.CD Feb 95.toast/Tool Chest/Development Tools & Languages/Macintosh Common Lisp Related/CLiCC-CodeWarrior-0.6.2/CLiCC⁄CodeWarrior 0.6.2 README

Text File | 1994-09-12 | 7.7 KB | 154 lines | [TEXT/ttxt]

MacCLiCC 0.6.2
==============

Here are a few notes about the MCL 2.0.1 port of CLiCC, the University of Kiel’s
Common Lisp to C compiler.

In the interest of space (specifically, so I could get the StuffIt archive to
fit on one high-density floppy), I’ve removed various UNIX/non-MCL files such
as makefiles, installation notes, and so on.  Kiel had also begun to experiment
with an alternative object-representation system, but as of this writing, it
only works with GNU C, so I removed that as well.  I did, of course, leave Kiel’s
copyright notice intact.  If any of this bothers anyone, the FTP site for the
original archive in its entirety is given at the end of this file.

First, you should read all of the README’s in the various subdirectories,
although I’ll attempt to provide all of their critical information in this file.

The Common Lisp code is CLtL1, and the C code is K&R; keeping these two facts in
mind is really all that’s necessary to port the code.

Porting the Lisp portion of the code turned out to be a relatively simple
matter of adding a few #+:mcl conditionalizations to the code here and there.
Most of them (and there aren’t that many) are in clcload.lisp, in the
:src:compiler: folder.  Basically, I

• Load the CLtL1 compatibility library
• Add the directory of the current-loading file to the module search path so
  that (require …) doesn’t freak
• Import a variety of CLOS symbols into the CLICC package because they wind up
  being unbound as far as the CLICC compiler is concerned otherwise
• Add a binding for *default-pathname-defaults* to the CLICC function so that
  (require …) can find files in the home: logical host (very helpful for when
  you drag the main source file to the CLiCC application and the file require's
  other files in the same folder)
• Conditionalize the setup-clcload-pathnames function.

In config.lisp, I

• Provide definitions for *CLICC-PATH-STRING*, *LISP-DEF*, and *SYS-DEF*.

That’s it.  All you need to do to build the CLiCC compiler, then, is fire up
MCL 2.0.1, get it set up the way you like, then load :src:compiler:clcload.lisp.
When it’s done loading, you should probably (in-package :user), then
(save-application "CLiCC" :init-file "init").  To use the compiler, the easiest
thing to do is to drag a .lisp file to your CLiCC compiler, which has the effect
of making the home: logical host refer to the folder containing the .lisp file.
Then type (clicc "main.lisp") or what have you and let ’er rip (be sure to read
the docs to see all of the keyword parameters to the clicc function; you may
want/need to use some of them).

Now for the runtime system (:src:runtime:c: and :src:runtime:lisp2c:).

It’s huge, on the order of a million and a third lines of C.  Don’t be daunted,
though.  I’ve already created CodeWarrior 1.0a2 PowerPC projects for the three
libraries in :src:runtime:c: and the one in :src:runtime:lisp2c: so that’s one
less thing for you to worry about.

You will need to copy inline.h, lisp.def, lisp.h, and lisp.syntax from the
:src:runtime:lisp2c: folder to the :lib: folder.

Actually, :src:runtime:c: only contains two .µ files and an additional .h file
of my own creation, nomain.h.  To build the main.lib, initialize.lib, and
rtc.lib files:

• Open main.µ with CodeWarrior C/C++ PPC 1.0a2
• Select CodeWarrior’s preferences via the toolbar or Edit menu
• Select “Language” in the preferences dialog’s icon list
• Make sure that the “Prefix File” field is empty
• “OK” the dialog away.  You’ll be warned about the need to recompile if you
  actually changed the configuration.  “OK” this away, too
• Select “Build Library” from the Project menu, and name the library “main.lib”

Repeat the above, but ensure that the “Prefix File” field contains “nomain.h”
and name the resulting library “initialize.lib”.  The story here is that CLiCC
can produce either entire programs (i.e. with a main function, and presumably
using stdio) or modules that don’t have a main, and are suitable for linking
into other code.  Put main.lib in your project in the first case, and
initialize.lib in for the second.

Now open rtc.µ.  There’s nothing weird about it at all, so just select “Build
Library” from the Project menu and name the library “rtc.lib”.

Next open rtl.µ, in the :src:runtime:lisp2c: folder.  It’s gargantuan, so be
patient.  There’s nothing weird about it but its size, so select “Build Library”
from the Project menu and go eat dinner--at least if you’re using a Quadra 800
like I am.  If, on the other hand, you’re using a Power Macintosh 8100/80, lucky
dog, then go get a cup of coffee--maybe.  When it’s done, name the resulting
library “rtl.lib”.

Incidentally, for those who are interested in the bootstrapping process, rtl.lib
was the biggest thorn in my side.  First of all, there was a struct and a set
of macros involving the struct that, while apparently valid K&R C, just weren’t
getting past either CodeWarrior or Symantec.  Specifically, trying to declare
an open array of these structs and initialize the array with char *’s cast to
longs for the sake of the struct wasn’t working.  Oddly, redefining the struct
to include char *’s instead of longs and casting the various longs to char *’s
when necessary works just fine.

Also, a large number of the .c files in rtl.lib redefine functions, and not
always with exactly the same code.  I’ve used MPW Link-like rules to weed these
out of the project: I kept the first occurrance.  Generally the first one has
seemed to be the larger of the two when there’s been a difference, perhaps due
to error-checking or something that’s missing in the other version.  It’s quite
possible, even likely, that these duplicate definitions are the result of
CLiCC self-compiling using different settings.  Unfortunately, as far as I can
tell, the makefiles from the UNIX version of CLiCC just compile and link all
.c files and the duplicate definitions somehow get automagically weeded out--
probably by causing link warnings rather than errors.  Hence my approach of
keeping the first occurrance.

Finally, given the addition of :lib: to the search path for the project, and the
checking of the “Treat <…> as "…"” checkbox, CodeWarrior insisted on finding
its PowerPC C++ Runtime library source file startup.c instead of the startup.c
that belongs to rtl.lib, so I renamed rtl’s startup.c to lstartup.c and replaced
its entry in the project.

If you have the CLiCC application, the rtc.lib library, the main.lib library,
the initialize.lib library, and the rtl.lib library, then you have a fully-built
CLiCC system, and you’re loaded for bear.

Go ahead; take it for a spin.  Open up :src:test: and drag testmain.lisp onto
the CLiCC application.  Once it’s launched, type (clicc "testmain.lisp") and
watch the messages fly by.  Quit CLiCC when it’s done, and open testmain.µ in
CodeWarrior C/C++ PPC 1.0a2.  Go ahead and build the app(!) and take it for a
test drive.

Final words: I’d have provided 68K CodeWarrior projects, too, but even with the
ANSI 250193 release of the ANSI libraries from Metrowerks, model far versions
are not included, so the linker chokes on the size of the data and a number of
the 16-bit code offsets to functions.  Hopefully DR2 will provide either a) all
possible configurations of the libraries or b) source code for the libraries
(although since they’re licensed from Plum Hall Associates, I doubt the latter).

TO DO
=====

If anyone wants to help with these... ;-)

• Provide support for MCL’s autoloading toolbox-call/interface-file scheme
• Provide libraries for MCL’s class library--check CD-ROM additional sources to
  see if Cambridge provided enough, or possibly wheedle sources from Cambridge

CREDITS
=======

Kiel wrote it; I got it from ftp.informatik.uni-kiel.de in kiel/apply.  If it
works, thank them.  If it doesn’t, blame me.  I’m:

Paul Snively
1079 Inverness Way
Sunnyvale, CA  94087
[phone]
[e-mail]